Applications that provide access to services such as banking, local weather information, stock transactions and the like are becoming ever more prevalent in society. Furthermore, today's users of application services are becoming more and more nomadic. They desire to access available services wherever they are, and regardless of the device they use for such access. The number of types of devices used to connect to information systems increases from day to day, ranging from larger fixed devices, such as a settop box, to small portable devices, such as PDAs (Personal Digital Assistants) or mobile phones. This proliferation of different devices has deep impact on the practical implementation of service applications.
More particularly, providing such an application on a wide range of terminals, and more generally in heterogeneous execution contexts, usually requires developing a dedicated version for each of these contexts. This increases the costs of these applications. Consequently, application service providers have to choose between two alternatives:
1—to provide the same application for multiple contexts, with heavy development and maintenance costs; or
2—to provide their applications for a single context, with lower costs, but a smaller user population.
Developing a monolithic, dedicated, instance of these applications for each of these devices leads to complexity at each of the following stages of application development and deployment:                during the development phase, because of the duplications in the different versions, and the well-known complexity of developing large software;        during software updates, as any minor modification in the service behavior implies rebuilding all application instances;        during software distribution, because each user might need all application instances, as they may use any of several devices. This implies providing them a huge amount of software;        and finally during execution, as users have to completely reinstall their applications each time they use them.        
In an effort to overcome these problems, applications have been developed as a collection of interconnected modules. A module is a piece of software code providing a well-defined function. It can for instance be an object, or a component. The assembly of software that constitutes the application can be formally described in a descriptor, that offers an abstract view of the application. It is rendered in a concrete form when it is translated into an executable instance of the application, i.e. module instances ready to run on various execution platforms (e.g. PCs, servers, or devices).
This modular structure facilitates the development and maintenance by isolating development concerns. A team can work on a specific aspect of the application, and the modification of one module's behavior doesn't impact other modules. Furthermore, the execution of the various modules can be distributed on different execution platforms, as long as they can communicate. This minimizes the implementation dedicated to the user device, by narrowing it to the behavior that has to be located on the user device (e.g. the user interface). It is then possible to keep a single implementation of the rest of the code, provided that it is always executed on the same kind of execution platform. However, multiple implementations can still be provided, in order to extend the range of possible execution platforms.
The deployment (i.e. the installation and preparation for execution) of such applications can be based on their abstract description, captured in their descriptor, that lists the modules' characteristics, their execution constraints (such as where they must be located), and their interconnections.
This approach for the development of applications is being applied in an increasing number of projects. Several technologies, including, but not limited to, COM+ from Microsoft Corporation, Enterprise Java Beans (EJB) from Sun Microsystems Inc., or CORBA Component Model from the Object Management Group (OMG) promote this approach. But there is not yet any solution to provide these applications to a large public using very heterogeneous devices.
The problem mostly resides in finding a means to present to the user device the application descriptor, and how this information can be automatically processed to produce an adapted application instance, transparently for the user. The solution must be applicable to most existing, emerging and future devices, and it must be safe to preserve confidentiality of the descriptor and to prevent illegal uses of the service.
Three solutions can be considered to store and deliver the descriptor to the device:
1—A first solution is to store the descriptor on a distant server. To access it, the user has to give the server address and a secret code, e.g. a PIN, to the device being used. After the connection, the device downloads the descriptor and personalization parameters. This solution doesn't suit a large user population, for it requires users to remember and enter on the device complex information, such as the server address. Furthermore, it will be generally entered differently on different devices. In addition, this solution requires the server to always be accessible, which inhibit use of the service in places where the server cannot be accessed (such as an enterprise intranet).
2—A second solution is to store on each device the descriptor of all applications. This is not feasible, as the set of possible applications is huge, unknown, and evolves daily.
3—A third solution consists in using a personal and portable storage medium, that each user would have with him, containing his application descriptors. It could for instance be a CD-ROM, a magnetic disk, or a memory stick. However these media are not directly usable in a number of devices, either because they have a very limited set of pluggable media (e.g. mobile phones), or because it would require an external dedicated reader (e.g. a CD-ROM reader for a PDA). In addition, storage media offer poor confidentiality of their content, as they do not have the processing capacity necessary to selectively present the data they hold. Cyphering their content would require a server to decypher it, with the defects presented in (1), and would still allow copies to be made. Furthermore, they cannot perform any processing on the descriptors, implying that all the adaptation has to be performed by the device. This would require each device to hold a dedicated implementation of the adaptation software.